tpm2: Update go-tpm2 version to v1.15.0

This adds initial APIs for resetting the TPM's dictionary attack counter
to replace the direct use of go-tpm2's
TPMContext.DictionaryAttackLockReset API.

This doesn't yet include the changes to Connection.EnsureProvisioned
which will create the authorization data that will be persisted by
snapd and passed to this new API - this is coming in a follow-up PR.

This is split into 2 APIs:
- Connection.ResetDictionaryAttackLock which will be supplied with data
  that will be provided by an updated EnsureProvisioned API.
- Connection.ResetDictionaryAttackLockWithAuthValue which will be
  supplied with a plain authorization value, previously chosen by snapd
  and provided to the current EnsureProvisioned API.

I did think about having this as 1 API, and handling the case where
decoding of the authorization data fails and treating it as an
authorization value if the length is 32 bytes. But as this value is
chosen by snapd and nothing in secboot enforces a size of 32 bytes, I
thought it was safer to have this as 2 APIs so that snapd can be
explicit about the format of the supplied data.

Fixes: FR-10809

This function shouldn't fail on unexpected event types. Instead, the
unexpected event types should trigger errors later on, resulting in more
appropriate error messages.

Fixes: FR-12830
Fixes: #514

This refines the checks that run on Intel systems so that appropriate
error messages are returned if the system is in manufacturing mode. The
changes are based on checks in the coreboot repository, specifically
https://github.com/coreboot/coreboot/blob/eb5bdf06b92534b6f66f612297a4ccb69008b4ac/src/soc/intel/common/block/cse/cse_spec.c#L15

Fixes: FR-12761
Fixes: #515

Based on the understanding that the ASP still acts as the root-of-trust
for measurement when PSB is disabled, permit platforms with an AMD CPU
when PSB is disabled. In this case, as firmware integrity is provided by
measured boot, we require profiles to be locked to PCR0 which is not
necessary when PSB is enabled.

tpm2: Add initial Connection.ResetDictionaryAttackLock APIs.

This adds initial APIs for resetting the TPM's dictionary attack counter
to replace the direct use of go-tpm2's
`TPMContext.DictionaryAttackLockReset` API.

This doesn't yet include the changes to `Connection.EnsureProvisioned`
which will create the authorization data that will be persisted by
snapd and passed to this new API - this is coming in a follow-up PR.

This is split into 2 APIs:
- `Connection.ResetDictionaryAttackLock` which will be supplied with data
  that will be provided by an updated `EnsureProvisioned` API.
- `Connection.ResetDictionaryAttackLockWithAuthValue` which will be
  supplied with a plain authorization value, previously chosen by snapd
  and provided to the current `EnsureProvisioned` API.

I did think about having this as 1 API, and handling the case where
decoding of the authorization data fails and treating it as an
authorization value if the length is 32 bytes. But as this value is
chosen by snapd and nothing in secboot enforces a size of 32 bytes, I
thought it was safer to have this as 2 APIs so that snapd can be
explicit about the format of the supplied data.

Fixes: FR-10809

…-optin

efi, efi/preinstall: Allow opt-in to secure boot being in user mode.

The preinstall checks currently require a system to be in deployed mode
(for UEFI versions >= 2.5). Relax this to allow an opt-in to user mode
for systems that run UEFI versions >= 2.5 but where the firmware
settings don't permit enabling deployed mode.

To support this, a new `WithSecureBootUserMode` option is added for
`AddPCRProfile`. If this option is supplied on a system that is in user
mode, 2 branches will be created. One of these will include the user
mode related measurements and the other branch will be for deployed
mode, which allows a system to transition from user mode to deployed
mode without requiring a recovery key.

This is an opt-in rather than automatic to avoid the scenario where a
system is initially in deployed mode but a later firmware configuration
change reverts to user mode, the user enters their recovery key on the
next boot and then snapd automatically repairs with a PCR profile that
includes the newly degraded setting. In this case, we want the user to
explicitly opt-in to this as an acknowledgement that the firmware
configuration has been changed.

Fixes: FR-12184
Fixes: #502

…nufacturing-mode-check

Preinstall improve csme manufacturing mode check.

This refines the checks that run on Intel systems so that appropriate
error messages are returned if the system is in manufacturing mode. The
changes are based on checks in the coreboot repository, specifically
https://github.com/coreboot/coreboot/blob/eb5bdf06b92534b6f66f612297a4ccb69008b4ac/src/soc/intel/common/block/cse/cse_spec.c#L15

Fixes: FR-12761
Fixes: #515

efi/preinstall: relax checkSecureBootPolicyForDegradedFirmwareSettings.

This function shouldn't fail on unexpected event types. Instead, the
unexpected event types should trigger errors later on, resulting in more
appropriate error messages.

Fixes: FR-12830
Fixes: #514

efi/preinstall: Don't require Platform Secure Boot on AMD.

Based on the understanding that the ASP still acts as the root-of-trust
for measurement when PSB is disabled, permit platforms with an AMD CPU
when PSB is disabled. In this case, as firmware integrity is provided by
measured boot, we require profiles to be locked to PCR0 which is not
necessary when PSB is enabled.

…d before the separator

This is a follow up to #442 for
the efi/preinstall package.

efi/preinstall: Permit pre-OS image verification events to be measured before the separator.

This is a follow up to #442 for the efi/preinstall package.

Some AMD systems measure events with unknown event types to PCR7. We
should just permit these.

Fixes: FR-12925
Fixes: #521

…sed for arm64 (#529)

…PCR4

We currently consider any pre-OS EV_EFI_BOOT_SERVICES_APPLICATION event
that isn't Absolute to be a sysprep app. However, ignore any events
loaded from flash. This should fix compatibility with some HP systems
which measure multiple EV_EFI_BOOT_SERVICES_APPLICATION events
associated with various firmware components during normal boots.

Fixes: FR-12927
Fixes: #509

As we convert the numerical recovery key into a cryptographic key, we
can be more relaxed about the parsing. Rather than permitting each group
of 5 digits be separated by an optional '-', just permit an arbitrary
number of '-' or whitespace characters intead.

Fixes: FR-11924

Relax recovery key parsing.

As we convert the numerical recovery key into a cryptographic key, we
can be more relaxed about the parsing. Rather than permitting each group
of 5 digits be separated by an optional '-', just permit an arbitrary
number of '-' or whitespace characters instead.

Fixes: FR-11924

…on-hp

efi/preinstall: Permit pre-OS application launches from SPI flash in PCR4.

We currently consider any pre-OS EV_EFI_BOOT_SERVICES_APPLICATION event
that isn't Absolute to be a sysprep app. However, ignore any events
loaded from flash. This should fix compatibility with some HP systems
which measure multiple EV_EFI_BOOT_SERVICES_APPLICATION events
associated with various firmware components during normal boots.

Fixes: FR-12927
Fixes: #509

TPMs based on versions of the refeference library older than v1.38 may
not implement TPM_CAP_AUTH_POLICICES. The preinstall checks currently
rely on this in order to determine whether TPM hierarchies have an
authorization policy set.

The existence of an authorization policy isn't relevant if the
hierarcy's authorization value isn't set, as the empty authorization
value can be used to clear the policy. In the case where the
authorization value is unset, there's no point in checking for the
existence of a policy.

Only check for the existence of an authorization policy for the lockout
hierarchy if it has an authorization value. In this case, the presence
of a policy is presented in the error message as additional information.
We take ownerhip of the lockout hierarchy in
tpm2.Connection.EnsureProvisioned, and for now, this function will clear
any policy before the authorization value is set. A subsequent PR will
set a more appropriate policy based on the requirement to be able to
rotate the authorization value safely during reprovisioning.

Fixes: #408

… mode

Access to the HFSTS registers via the HECI is not possible on systems
that use Intel's High Assurance Platform mode. This means that we can't
check the BootGuard policy. However, the startup ACM mirrors some
BootGuard policy settings to a MSR, so we can check this as a fallback
in this case.

There are some limitations here - it's not possible to check some bits
that indicate the platform has properly transitioned out of
manufacturing mode, and the error enforcement bits of the BootGuard
policy are not available either. However, there are no combinations of
the other policy bits that are duplicated with different error
enforcement bits for any of the recognized profiles, so this doesn't
matter.

Note that the reporter of this issue also noted that turning on HAP mode
resulted in an unexpected EV_EFI_ACTION event being measured to PCR7 on
their system. This doesn't fix that yet because I'm still waiting on a
response from the reporter.

efi/preinstall,tpm2: Don't fail due to lack of TPM_CAP_AUTH_POLICIES.

TPMs based on versions of the refeference library older than v1.38 may
not implement `TPM_CAP_AUTH_POLICICES`. The preinstall checks currently
rely on this in order to determine whether TPM hierarchies have an
authorization policy set.

The existence of an authorization policy isn't relevant if the
hierarcy's authorization value isn't set, as the empty authorization
value can be used to clear the policy. In the case where the
authorization value is unset, there's no point in checking for the
existence of a policy.

Only check for the existence of an authorization policy for the lockout
hierarchy if it has an authorization value. In this case, the presence
of a policy is presented in the error message as additional information.
We take ownerhip of the lockout hierarchy in
`tpm2.Connection.EnsureProvisioned`, and for now, this function will clear
any policy before the authorization value is set. A subsequent PR will
set a more appropriate policy based on the requirement to be able to
rotate the authorization value safely during reprovisioning.

Fixes: #408

…us-msr-in-hap-mode

efi/preinstall: Fall back to checking the BootGuard status MSR in HAP mode.

Access to the HFSTS registers via the HECI is not possible on systems
that use Intel's High Assurance Platform mode. This means that we can't
check the BootGuard policy. However, the startup ACM mirrors some
BootGuard policy settings to a MSR, so we can check this as a fallback
in this case.

There are some limitations here - it's not possible to check some bits
that indicate the platform has properly transitioned out of
manufacturing mode, and the error enforcement bits of the BootGuard
policy are not available either. However, there are no combinations of
the other policy bits that are duplicated with different error
enforcement bits for any of the recognized profiles, so this doesn't
matter.

Note that the reporter of this issue also noted that turning on HAP mode
resulted in an unexpected EV_EFI_ACTION event being measured to PCR7 on
their system. This doesn't fix that yet because I'm still waiting on a
response from the reporter.